ラックグループ内CTF「LACCON 2022」で作問した話

こんにちは、デジタルペンテスト部のst98です。

私がこのブログでこれまで投稿してきた記事は、いずれもCTFに参加する側の視点から書いたwriteupでした。本記事では、CTFの問題を作る側の視点に立ってお話をしたいと思います。

弊社では、毎年「LACCON」というラックグループ内CTFが開催されています。このCTFにいくつか問題を提供したので、どのように問題を作ったか、具体的にどんな問題を出題したかといったことをご紹介します。

冒頭でも述べましたが、LACCONはラックグループ内で毎年開催されているCTFです。LACCONのもうちょっと詳しい話については、LAC WATCHで公開されている記事がありますので、そちらをご覧ください。

www.lac.co.jp

私は2021年度と2022年度のLACCONに参加しましたが、たとえば2022年度ではCAN/UDSについてステップバイステップで学べるものがあったり、パズルのように既知の脆弱性を悪用する方法を考える必要のあるものがあったりと、出題される問題はバラエティに富んでいる印象があります。

LAC WATCHの記事中にも書かれていますが、LACCONでは「作問者にも参加者にも学びのある場にする」というスローガンが掲げられています。基本的な方針として、学びに重点を置くというLACCONの方向性にもとづいて作問しました。

ただし、これは一般的なCTFで出るようなパズル要素のある問題だったり、難しめの問題だったりといったものを出題しないということを意味するものではないと思っています。たとえ解ききれなかったとしても、たとえばwasmファイルのリバースエンジニアリングはこうすればいいのかとか、このCVE番号の脆弱性はこういう原理だったのかとか、問題に挑戦する中で何かしらを得られればよいかなと思っています。

私は、ただツールを使うだけで解けたり、ググって出てくる攻撃手法をそのまま適用できたりといった問題は、ゲームとして面白くないと感じています。簡単な問題であっても少しひねり、たとえば対象のシステムを理解して、自分でexploitを書く必要があるようにするというような形で、なるべく安直な方法では解けない問題にするよう心がけました*1。

また、フラグを得るためには、与えられた情報から非合理な飛躍を必要とするような、いわゆるエスパー要素がないこと、酷似する過去問がないこと*2、Web問やPwn問ではソースコードをできるだけ公開する*3といった点でも気をつけました*4。

LACCONでは、作問者かつ参加者として、問題を提供した場合でもCTFに参加できるようになっています。作問者の特権として、自分が作った問題であってもそれを解いて得点できるわけです。そこでアドバンテージを得たいというよこしまな気持ちがなかったというと嘘になりますが、どちらかというと大会の盛り上がりに貢献できればというモチベーションから、13問を作問しLACCON 2022に提供しました。

LACCON 2022に提供した問題には、以下のようなものがありました。

得意分野であるWebの問題ばかり作っていようかなとも思ったのですが、CTF全体で見たときに特定のカテゴリに問題が偏っているのもなんですし、様々なカテゴリで問題を作って知見を広げたいという気持ちもあり、色々作りました。

さて、ここからは、LACCON 2022に提供したうちの1問である「[Web] Hadena Star」についてご紹介します。

次のような問題文と、ソースコードを参加者に提供していました。

世の中には、記事中の一部の文章に「スター」をあげられるブログサービスがあるそうです。   いいなーと思ったので、あれを実装してみました。機能の名前は「はでなスター」です。   (問題サーバのURL)

もしよろしければ、解法を読む前に以下のリンクからソースコードのダウンロードをして docker compose up -d でサービスを立ち上げ(8004/tcp で問題サーバが立ち上がっています)、この問題に挑戦してみてください。

gitlab.com

問題サーバのURLにアクセスすると、「はでなダイアリー」というサービスが表示されます。

これはシンプルなブログサービスで、ユーザ登録を済ませるとブログ記事の投稿ができるようになっています。記事は全体に公開するか、それとも公開範囲を制限するかを選ぶことができます。もし後者を選択した場合には、投稿者以外が記事を閲覧しようとすると、次のように権限が足りない旨のエラーが表示されます。

「はでなダイアリー」の目玉機能として、「はでなスター」というものがあります。これは、記事の一部分を選択してスターを付与できるという機能です。たとえば、piyo pi というテキストに付与すると、以下のように記事ページ下部に付与したユーザが表示されます。ユーザのアイコンにカーソルをあわせると、そのスターの付与対象であるテキストがハイライトされます。

「はでなスター」の付与時には、以下のように star.php というAPIにPOSTが飛びます。where というキーに選択したテキストが入っているわけですが、HTTPリクエストを書き換えることで記事に含まれていないテキストに「はでなスター」を付与しようとしても、APIに弾かれます。

さて、この問題では何が求められているのでしょうか。ソースコード中でフラグを探すと、init/init.php のデータベースを初期化する処理が見つかります。少し読みづらいですが、ランダムなIDでフラグを内容に持つ記事が存在しているとわかります。

記事がほかのユーザから閲覧できるかどうかのフラグである published は 0 (投稿者本人にしか閲覧できない)に設定されており、普通には読むことができないことがわかります。